Methods of controlling and visualizing processes have been known in practice for a long time. In general, they are software systems that are used for controlling physical processes. In the case of these software systems, it is necessary to guarantee a deterministic behavior as regards the cycle time of the sampling of signals for purposes of keeping dead times of the closed loop system small and constant. The often desired, simultaneous visualization or saving of controlled variables complicates this undertaking, since system resources, such as the display screen, hard disk, or the like of a computer can only be used exclusively, i.e., by only one system resource, at any given time.
There exist so-called multitasking operating systems, which are capable of handling several tasks, i.e., functions, at the same time. In addition, there exist so-called multithreading operating systems, wherein the individual tasks are divided into so-called threads. A thread is understood as the control flow that is inherent in the process of a program. Multitasking and multithreading operating systems are of special advantage, since in the process of executing commands, for example, the CPU of a computer must over and over again await the response from, for example, programs or peripheral devices. The CPU is able to assign this turnaround time as computing time to other processes by means of multitasking or multithreading. Consequently, the execution of individual commands of the different programs does not occur in parallel, but in so-called time windows or even time slices, since the CPU can execute only one command at the same time. A so-called scheduler, an integral part of the operating system, which allocates priorities to the individual tasks or threads, undertakes to set the sequence of the execution. However, such an operating system involves at any time the risk that the tasks or threads are blocked, when an output is attempted, since other tasks or threads tie up the output. This blocking stops the outputting task or thread, until the already started tasks or threads of other processes of the same or a higher priority are completed. In this process, for example, a closed loop control system is also blocked. Such a blocking is unacceptable for a real control, which goes beyond a simulation of the closed loop control system.
In general, these problems are solved by a special hardware with dual-ported, shared-memory components. As a result of the largely decoupled access to the memory in terms of time, a blocking of a thread with a high priority, for example, the thread of control will not occur. A mere software solution, however, is not possible in this way, which will inevitably lead to higher costs by the additionally used hardware.
In the case of a mere software-type solution, the transfer of data between tasks or threads is synchronized by means of so-called semaphores. The semaphores are used to manage many system resources of a computer, such as the display screen, hard disk, or the like. As described above, for example, should tasks and threads want to access a printer at the same time, such would not be possible. Accordingly, the task or thread with the highest priority will first start with printing. The system will then put the semaphore, which describes the status of the printer, on engaged, thereby queuing the requests of other tasks or threads. Once the system resource—the printer—is again ready, the semaphore will be reset to available. If still further requests are queued, it will now be possible to process the same. Thus, a semaphore is a special kind of counter.
Accordingly, the semaphores are used to avoid that the producer of data rewrites a memory area, in which the data are written, while the consumer of data is in the process of reading the data from this memory area. Should a simultaneous reading and writing of data occur in a multithreading operating system, one would have to expect a corruption of the data. For example, when a thread that produces data is writing in the memory a number consisting of eight bytes, the thread could be canceled after writing only a few bytes. The number having been written incompletely in the memory area would then—after changing the threads—be read and, thus, be incorrectly interpreted by the reading thread, which consumes the data. Accordingly, a reliable and uncorrupted transfer of data is possible only by a one hundred percent synchronization, even in the case of simple data types, such as a number.
While small quantities of data can be rapidly copied, synchronization will always involve the risk that the thread, which produces the data, such as, for example, a thread for controlling a process, is blocked. The blocking may last substantially longer than the mere copying action, since the thread, which consumes the data, such as a thread for visualizing the data, can in turn be blocked itself. In general, it is not possible to estimate the time, during which the thread of control is blocked. It may, however, amount to as much as a few seconds, since one has to await the release of the system resource, for example, the display. Likewise, the use of other exclusively usable system resources, such as the hard disk, voice card, interfaces, exclusively usable software modules, or the like, can also lead to a delayed response time.
A further possibility of solution is hard real time operating systems, which make available special modules that permit a nonexclusive use of system resources. While this technique considerably facilitates for a programmer the dealing with system resources, it has the disadvantage that the necessary serialization of the access to shared system resources requires first-in-first-out (FIFO) memories, which are realized in the software. In this instance, the FIFO memories function as queues. Since the system resources for a queued-up thread are never blocked, there is no possibility of making a meaningful use of this data, for example, for purposes of loading the display with additional tasks, when a step-by-step display of the data is already no longer possible. Furthermore, these specialized real time operating systems are normally not as widely distributed and standardized as universal operating system, such as, for example, Windows, Linux, or the like. The costs for training and the costs resulting from royalties or the like are therefore quite high for such real time operating systems.
It is therefore an object of the present invention to describe a method of controlling and visualizing processes of the initially described kind, which permits a deterministic behavior without increased costs for software or hardware.